Document Selector
Volume Number: 2
Issue Number: 9
Column Tag: C Workshop
Batch Document Selector in Mac C 
By Frank Alviani, Contributing Editor
Everybody Needs a Front Man...
One of the more annoying "features" of the Finder is its habit of keeping all
selections within a single folder; files selected in folder 'A' suddenly unselect when you
click outside it. This is restrictive if you have a hard disk: typically there's one copy of
an application, with files scattered all over the back 40. If you wanted to print a batch
of them, from different folders, you were out of luck and had to babysit the Mac all the
way thru. What we need is a utility that selects multiple files from a user dialog, then
processes or sends the whole lot off to some other program or function. In otherwords, a
front man to do a batch job for us! The Front Man is just such a general-purpose
document-batching utility.
The Front Man was written to overcome this Finder limitation by providing a
general purpose multi-file selector, and to show the use of the _Launch trap from 'C'.
While obscurely documented in Inside Mac, there is a lot of potential in this trap! A
number of other principals are also shown here, such as user configurability, HFS
compatibility, and the use of the finder parameters. Following the guidelines here will
teach you how to write HFS programs that work, and explain why some things are still
tough to do with an HFS type file structure.
Front Man: List Selection of Files
Choose "Pick" to bring up a standard getfile dialog box. Each time you select a
file, it is added to the list to be passed via the finder parameters to another application.
Hit the cancel button to quit selecting. An exception is if a file name ends with '.FILE' -
in this case, the file is assumed to contain a list of file names (1 per line) which are
each added to the finder parms. It can (optionally) display ALL file types, not just TEXT
files (so you can batch files to WORD, MacWrite, etc.). The only shortcoming is that
when using a file of filenames, it doesn't look up the directory entry for each file named,
and get the proper filetype; instead, the filetype of the batch file is applied to each
named file (this limits the utility of batch files to TEXT files, but offers "an exercise
for the student").
Choose "Launch". If you are in "interactive" mode, a standard getfile dialog box
will appear displaying applications. If you are in "hardwired" mode, the application
whose name is in a STR resource is launched automatically, with the list of files sent on
in your behalf!
Front Man can (optionally) cause the launched application to either print or just
open the selected files.
Uses of the Launch and Chain traps
One of the most common arrangements in traditional data processing systems was
chained programs. Program 'A' ran to sort or preprocess a bunch of data, then chained
to program 'B' which did the reports or other interesting work on the data. This was
done to be able to work with large data sets on smallish machines (by today's
standards), and also allowed very long processing runs to be broken up into smaller
pieces. Programmers also found it more convenient in many respects - the smaller
programs were easier to debug and write: all the classical virtues of modularity.
The difference between chaining and launching is small: when you chain to a
program on a Mac, the application heap is preserved essentially intact. When you
launch another program, the heap is reset except for the desk scrap. ExitToShell, for
example, simply launches the program whose name is found in low memory at $2E0.
Chaining is thus useful when the different programs want to pass blocks of data in
memory, as might be the case in an "integrated" processing package; launching is more
useful in more general-purpose "front ends" such as this.
"Front Ends" have a small but useful niche to fill. For example, a "program
tuner" might batch a number of 'C' files together, have them all compiled to assembler,
optimize at this level, then assemble the tuned files. Also, a set of options (ala
conventional 'C' command-line parameters) could be ga thered and placed in a block in
system memory before launching another application which would know where to look...
Basics of the Finder Parameters
The finder parameters are what make "front ending" an application possible.
They consist of 3 pieces of information:
(1) A "message" to the application about what to do with the files. The operation
requested is applied to ALL the files named.
(2) A count of how many files to process.
(3) A list of the files to process, with complete location information ( volume
reference number as well as file name).
Currently, the only messages in use are "print" and "open". Since "message" is a
16-bit field, this leaves 65,766 operations available! There is no reason why
"private" message types can't be developed, such as "sort each of these in ascending
order", "sort each in descending order", "merge these all together ", etc. as long as the
application getting the message is equipped to deal with the additional messages! In an
even more flexible system, the first file in the list could contain parameters that
dictate what processing is done to each of the following files in the list - that is,
Referenced by (2):